05. 책임과 메시지

📌 Contents

📌 자율적인 책임

• 객체지향의 공동체를 구성하는 기본 단위는 자율적인 객체
• 자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체
• 객체가 행동을 하는 이유는 요청을 수신했기 때문
• 요청을 처리하기 위해 객체가 수행할 행동을 책임이라고 함
• 적절한 책임이 자율적인 객체를 낳고, 자율적인 객체들이 모여 유연하고 단순한 협력을 이룸

자신의 의지에 따라 행동할 수 있는 자유

• 너무 구체적인 책임이 할당되면 객체의 자율성의 제한함
• 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이여야 함

너무 추상적인 책임

• 너무 구체적인 책임도 문제지만 의도를 명확하게 표현하지 못할 정도로 추상적인 것 역시 문제
• 추상적이고 포괄적인 책임은 협력에 유연성을 주지만 의도를 명확하게 설명할 수 있는 수준에서 추상적이여야 함
• 이러한 기준은 문맥에 따라 다르기 때문에 현재의 문맥에 가장 적합한 책임을 선택할 수 있는 날카로운 안목을 기르자!

어떻게가 아니라 무엇을

• 어떻게 행동할 것인지가 책임의 수준에서 어느정도 결정돼 있으면 자율성이 제한 될 수 밖에 없음

📌 메시지와 메서드

메시지

• 객체의 행동을 유발하는 행위를 메시지-전송이라고 함
• 전송하는 메시지를 가리키는 부분을 메시지 이름이라고 함
• 메시지를 전송할 때 추가적인 정보가 필요하면 메시지 인자를 통해 추가 정보를 제공할 수 있음
• 메시지-전송은 수신자와 메시지의 조합
• 메시지는 메시지 이름과 메시지 인자의 조합
• 즉, 메시지-전송은 수신자와 메시지 이름, 메시지 인자의 조합: ex) 모자장수, 증언하라(어제, 왕국)
• 객체가 수신할 수 있는 메시지의 모양은 객체가 수행할 책임의 모양을 결정
• 객체들이 서로 협력하기 위한 유일한 수단은 메시지이고 메시지를 처리하는 것은 자율적으로 선택할 수 있음

메서드

• 메서드는 메시지를 처리하기 위해 객체가 내부적으로 선택하는 방법
• 객체는 수신한 메시지가 처리할 수 있다고 판단되면 자신에게 주어진 책임을 다하기 위해 메서드를 선택
• 메시지는 "어떻게" 수행될 것인지는 명시하지 않고, 어떤 메서드를 선택할 것인지는 전적으로 수신자의 결정에 좌우됨
• 메시지를 수신한 객체가 실행 시간에 메서드를 선택할 수 있다는 사실은 다른 프로그래밍 언어와 객체지향 프로그래밍 언어를 구분짓는 핵심적인 특징 중 하나
• 이것은 프로시저 호출에 대한 실행 코드를 컴파일 시간에 결정하는 절차적인 언어와 확연이 구분되는 특징

다형성

• 다형성이란 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것
• 서로 다른 타입에 속하는 객체들이 동일한 메시지를 수신할 경우 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 메커니즘
• 서로 다른 객체들이 다형성을 만족시킨다는 것은 객체들이 동일한 책임을 공유한다는 것을 의미
• 기본적으로 다형성은 객체들의 대체 가능성을 의미
• 다형성은 객체들의 대체 가능성을 이용해 설계를 유연하고 재사용 가능하게 만듬
• 다형성은 수신자의 종류를 캡슐화함
• 다형성은 송신자와 수신자 간의 객체 타입에 대한 결합도를 메시지에 대한 결합도로 낮춤으로써 달성
• 다형성을 사용하면 메시지를 이해할 수 있는 어떤 객체와도 협력할 수 있는 유연하고 확장 가능한 구조를 만들 수 있음

📌 메시지를 따라라

• 객체지향 애플리케이션의 중심 사상은 연쇄적으로 메시지를 전송하고 수신하는 객체들 사이의 협력 관계를 기반으로 사용자에게 유용한 기능을 제공하는 것
• 클래스를 중심에 두는 설계는 유연하지 못하고 확정하기 어려움
• 시스템을 정적인 클래스들의 집합이 아니라 메시지를 주고받는 동적인 객체들의 집합으로 봐야함
• 메시지가 아니라 데이터를 중심으로 설계하는 데이터-주도 설계는 객체의 내부 구조를 객체 정의의 일부로 만들기 때문에 객체의 자율성을 저해함
• 메시지를 중심으로 한 설계 방법은 책임-주도 설계임

책임-주도 설계

• 책임-주도 설계의 기본 아이디어는 객체들 간의 주고받는 메시지를 기반으로 적절한 역할과 책임, 협력을 발견하는 것
• 메시지가 수신자의 책임을 결정
• 책임-주도 설계의 핵심은 어떤 행위(What)가 필요한를 결정한 후에 이 행위를 수행할 객체(Who)를 결정하는 것: What/Who 사이클
• 죽, 협력이라는 문맥 안에서 필요한 메시지를 결정한 후에 메시지를 수신하기에 적합한 객체를 선택하고, 수신된 메시지가 객체의 책임을 결정
• 수신 가능한 메시지들이 모여 인터페이스를 구성
• What/Who 사이클이라는 용어는 역할을 수행할 객체의 인터페이스를 발견하기 위해 메시지를 이용하는 책임-주도 설계의 핵심 아이디어를 명확하게 표현
• 객체간의 메시지는 객체의 책임을 결정하는데, 책임-주도 설계에서는 What/Who 사이클에 따라 협력에 참여할 객체를 결정하기 전에 협력에 필요한 메시지를 먼저 결정함

묻지 말고 시켜라

• 메시지를 결정하기 전까지는 객체에 관해 고민하지 말아야 함
• 메시지를 결정하는 시점에서는 어떤 객체가 메시지를 수신할 것인지를 알 수 없기 때문에 메시지 송신자는 메시지를 수신할 객체의 내부 상태를 볼 수 없음
• 즉, 메시지 중심 설계는 캡슐화를 증진시키고, 송신자와 수신자가 느슨하게 결합됨
• 송신자는 수신자가 어떤 객체인지 모르기 때문에 객체에 대해 꼬치꼬치 캐물을 수 없음
• 단지 자신이 전송한 메시지를 잘 처리할 것이라고 믿고 메시지를 전송해야함
• 이런 스타일이 묻지 말고 시켜라 (Tell, Don't Ask)임
• 묻지 말고 시켜라 스타일은 객체를 자율적으로 만들고 캡슐화를 보장하며 결합도를 낮게 유지시켜주기 떄문에 설계를 유연하게 만듬
• 객체가 자신이 수신할 메시지를 결정하게 하지 말고 메시지가 협력에 필요한 객체를 발견하게 해야 함

📌 객체 인터페이스

• 일반적으로 인터페이스란 어떤 두 사물이 마주치는 경계 지점에서 서로 상호작용 할 수 있게 이어주는 방법이나 장치를 의미
• 인터페이스는 세상 어느 곳에나 존재: ex) 말과 글, 손가락, TV 리모컨, 그래픽 사용자 인터페이스, 애플리케이션 프로그래밍 인터페이스

• 일반적으로 인터페이스는 세 가지 특징을 가짐

• 인터페이스의 사용법을 익히기만 하면 내부 구조나 동작 방식을 몰라도 쉽게 대상을 조작하거나 의사를 전할 수 있음

• 인터페이스 자체는 변경하지 않고 단순히 내부 구성이나 작동 방식만을 변경하는 것은 인터페이스 사용자에게 어떤 영향도 미치치 않음

• 대상이 변경되더라도 동일한 인터페이스를 제공하기만 하면 아무런 문제 없이 상호작용 할 수 있음

• 객체가 다른 객체와 상호작용 할 수 있는 유일한 방법은 메시지 전송임

• 따라서 객체의 인터페이스는 객체가 수신할 수 있는 메시지의 목록으로 구성
• 객체가 어떤 메시지를 수신할 수 있는지가 객체의 인터페이스의 모양을 빚음

• 인터페이스는 내부 인터페이스와 공용 인터페이스로 구분
• 객체지향에서 자기 자신과의 상호작용도 메시지를 통해서만 이루어지기 때문에 내부에서만 접근 가능한 내부 인터페이스가 존재
• 내부 인터페이스와 구분하기 위해 외부에 공개된 인터페이스를 공용 인터페이스라고 함
• 객체가 협력에 참여하기 위해 수행하는 메시지가 객체의 공용 인터페이스의 모양을 암시
• 즉, 정확히는 객체의 공용 인터페이스를 구성하는 것이 객체가 수신할 수 있는 메시지의 목록

📌 인터페이스와 구현의 분리

• 맷 와이스펠드는 객체지향적인 사고 방식을 이해하기 위해서는 다음의 세 가지 원칙이 중요하다고 주장함
  • 좀 더 추상적인 인터페이스
  • 최소 인터페이스
  • 인터페이스와 구현 간에 차이가 있다는 점을 인식
• 첫 번째 원칙에 대해서는 앞에서 얘기 했고 두 번째 원칙은 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 말라는 것
• 불필요한 메시지는 공용 인터페이스에 포함하지 않아야 함
• 메시지를 따르면 최소 인터페이스를 얻을 수 있음
• 마지막 원칙은 매우 중요하다

구현

• 객체지향 세계에서 내부 구조와 작동 방식을 가리키는 고유의 용어는 구현임
• 객체는 상태를 가지지만 공용 인터페이스의 일부가 아님
• 상태를 어떻게 표현할 것인가는 객체의 구현에 해당
• 객체는 행동 즉, 메서드를 가지지만 메서드를 구성하는 코드 자체는 공용 인터페이스의 일부가 아님
• 메서드를 구현하는 코드 자체는 객체의 구현 부분에 포함
• 객체의 외부와 내부를 분리하라는 것은 객체의 공용 인터페이스와 구현을 명확하게 분리하라는 것임

인터페이스와 구현의 분리 원칙

• 훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체를 의미
• 이것은 객체를 설계할 때 공용 인터페이스와 구현을 명확하게 분리해서 고려해야 한다는 것을 의미
• 이를 인터페이스와 구현의 분리(separation of interface and implementation) 원칙이라고 함
• 이 원칙이 중요한 이유는 소프트웨어는 항상 변경되기 떄문
• 객체 내부인 구현을 변경에 대한 안전 지대로 만들어 객체 외부인 공용 인터페이스와 분리해야 함
• 그렇게 되면 외부에 영향을 주지 않고도 메서드를 자유롭게 변경할 수 있게 되고 객체의 자율성이 증가함
• 적절한 구현을 선택하고 이를 인터페이스 뒤로 감추는 것은 객체의 자율성을 향상시킬 수 있는 가장 기본적인 방법
• 객체 내부를 수정하더라도 객체 외부에 영향을 미쳐서는 안됨
• 객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때 뿐임

캡슐화

• 객체의 자율성을 보존하기 위해 구현을 외부로부터 감추는 것을 캡슐화라고 함
• 캡슐화를 정보은닉(infomation hiding)이라고 부르기도 함
• 객체지향의 세계에서 캡슐화는 두 가지 관점에서 사용
  • 상태와 행위의 캡슐화
  • 사적인 비밀의 캡슐화

• 상태와 행위의 캡슐화의 관점에서 캡슐화를 데이터 캡슐화라고 함
• 객체가 자율적이기 위해서는 자기 자신의 상태를 스스로 관리할 수 있어야 하기 때문에 데이터 캡슐화는 자율적인 객체를 만들기 위한 전제 조건임
• 프로그래밍 관점에서 주로 상태는 데이터, 행동은 프로세스로 구현됨
• 과거의 전통적인 개발 방법은 데이터와 프로세스를 엄격히 구분하지만, 객체지향에서는 객체라는 하나의 틀 안에 묶어 객체의 자율성을 보장
• 이것이 전통적인 개발 방법과 객체지향을 구분 짓는 가장 중요한 차이

• 객체도 사람처럼 개인적인 비밀이 노출되는 것이 민감함
• 객체는 외부의 객체가 자신의 내부 상태를 직접 관찰하거나 제어할 수 없도록 막기 위해 의사소통이 가능한 특별한 경로인 공용 인터페이스만 외부에 노출함
• 캡슐화를 통해 변경이 빈번하게 일어나는 불안정한 비밀을 안정적인 인터페이스 뒤로 숨길 수 있음
• 객체는 공용 인터페이스를 경계로 최대한의 자율성을 보장 받음

📌 책임의 자율성이 협력의 품질을 결정한다

• 책임이 얼마나 자율적인지가 전체적인 협력의 설계 품질을 결정하게 됨

• 이것에 대한 5가지 이유가 있음

• 자율적인 책임은 협력을 단순하게 만듬
  : 책임이 적절하게 추상화 됨

• 자율적인 책임은 객체의 외부와 내부를 명확하게 분리함
  : 요청하는 객체가 몰라도 되는 사적인 부분이 객체 내부로 캡슐화 되어 인터페이스와 구현이 분리 됨
• 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않음
  : 변경의 파급 효과가 객체 내부로 캡슐화되기 때문에 두 객체 간의 결합도가 낮아짐
• 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공함
  : 책임이 자율적일수록 협력이 좀 더 유연해지고 다양한 문맥에서 재활용 될 수 있음 -> 설계가 유연해지고 재사용성이 높아짐
• 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워짐
  : 책임이 자율적일수록 객체의 응집도를 높은 상태로 유지하기가 쉬워짐

책임이 자율적일수록
협력이 이해하기 쉬워지고,
객체의 외부와 내부의 구분이 명확해지며,
변경에 의한 파급효과를 제한할 수 있고,
유연하게 변경할 수 있는 동시에 다양한 문맥에서 재활용 할 수 있게 됨

책임이 자율적일수록
적절하게 "추상화"되며,
"응집도"가 높아지고,
"결합도"가 낮아지며,
"캡슐화"가 증진되고,
"인터페이스와 구현이 명확히 분리"되며,
설계의 "유연성"과 "재사용성"이 향상됨

❓ Questions

❓ 어떤 메서드를 선택할지와 언제 메서드를 결정하는지는 어떤 관련이 있을까?

• 객체지향에서는 메서드는 메시지의 수신자가 결정 할 수 있다고 나온다.
• 그래서 코드를 구현할 때 공용 인터페이스 따르는 객체들 각각이 매서드를 다르게 구현하면 다형성을 구현했다고 생각했다.
• 그런데 책에 다른언어와 객체지향 프로그래밍 언어의 차이가 메서드를 컴파일 시간이 아닌 실행 시간에 결정 할 수 있는 것이라는 말이 나온다.
• 객체들이 메시지에 대한 매서드를 다르게 구현하는 것, 즉 어떤 메서드를 선택할 것인지 결정하는 것이랑 메서드를 컴파일 시간이 아닌 실행 시간에 결정하는 것이랑 어떤 관계가 있지?

• 객체지향 프로그래밍 언어에는 오버라이딩이라는 기능이 있다.
• 오버라이딩은 상위 클래스에서 정의된 메서드를 하위 클래스에서 동일한 시그니처로 다시 정의하는 기능이다.
• 오버라이딩을 통해 다형성 즉, 객체들이 메시지에 대한 메서드를 자율적으로 결정할 수 있다.
• 오버라이딩된 메서드들은 실행 시간 (런타임)에 어떤 메서드를 실행할지 결정된다고 한다.
• 즉, 객체지향 프로그래밍 언어는 객체들이 메서드를 자율적으로 선택할 수 있기 위한 기능으로 실행 시간에 메서드를 결정할 수 있는 기능이 있는 것 같다.
• 그렇지만 꼭 런타임 시에 메서드를 결정해야만 객체들이 메서드를 자율적으로 선택할 수 있는 것을 구현할 수 있는 것인가?
• 오버라이딩 된 메서드들은 컴파일타임에 결정하면 안되나?

• 객체지향 언어에서 객체를 생성할 때 해당 객체를 저장할 메모리 공간을 런타임에 동적으로 할당한다. ex) 자바의 new 연산자
• 오버라이딩 시 메서드는 객체가 생성 될 때 결정되야 하기 때문에 오버라이딩 된 메서드들은 런타임에 메서드가 결정되야 하는 것 같다.

❓ 컴파일 시간(컴파일타임)에 결정되는 메서드 vs 실행 시간(런타임)에 결정되는 메서드

• 오버로딩 (컴파일타임): 동일한 매서드 이름을 가지면서 매게변수의 타입, 개수, 또는 순서가 다른 여러 메서드를 정의할 수 있는 기능
• 오버라이딩 (런타임): 상위 클래스에서 정의된 메서드를 하위 클래스에서 동일한 시그니처로 다시 정의하는 기능
• 오버로딩 된 메서드는 컴파일타임에 결정된다고 하는데 그럼 다형성과 관련이 없는 것인가?
• 동일한 메서드에 대해서 매개변수에 따라 내부 구현이 달라지는데 이건 다형성과 관련이 없나?

• 오버로딩 된 메서드들도 다형성을 구현한 것이다.
• 컴파일 시간에 메서드가 결정된다 해서 다형성이 아닌 것이 아니라 오버라이딩을 구현하기 위해 런타임에 메서드를 결정하는 기능이 객체지향 언어에서 필요한 것 같다.